
\chapter{Introduction}
\pagenumbering{arabic}%

\sysname{} (which stands for \sysname{} Implements Common Lisp%
\footnote{Thanks to Michał "phoe" Herda for suggesting this
  interpretation.}, pronounce it like ``sickle'') is a project with
the purpose of creating a collection of highly-portable
high-performance ``modules'' for developers of Common Lisp systems.
Such modules include ``standard libraries'' such as high-level
functions that operate on lists, high-level functions that operate on
sequences, the \texttt{format} function, the \texttt{loop} macro, the
\texttt{read} function, the \emph{pretty printer}, etc.  We believe
that the essence that defines the characteristics of a \commonlisp{}
implementation has to do with aspects such as object representation,
memory management, and compiler optimizations.  The modules of the
\sysname{} project neither rely upon nor dictate any of those aspects,
which is why we think they can be used by any \commonlisp{}
implementation, thereby removing some of the maintenance burden
resulting from multiple specific implementation of similar code.

However, the modules are not limited to functionality that is directly
provided by the \commonlisp{} language specification.  An existing
module%
\footnote{https://github.com/s-expressionists/Clostrum},
defines a \clos{} protocol for managing first-class global
environments, and another%
\footnote{https://github.com/s-expressionists/Trucler}
defines such a protocol for managing
the contents of the compilation environment during the early phases of
compilation.

Furthermore, even though these modules are part of the \sysname{}
\emph{project}, they may not be present in the \sysname{}
\emph{repository}.  Whenever a module is sufficiently independent of
the rest of the \sysname{} code base, we try to extract it into a
separate, independently maintained repository.

Initially, we planned to decrease the interdependence of modules as
much as possible by creating a partial order between the modules,
thereby enabling an implementation of a small subset of \commonlisp{}
to become a fully compliant implementation by adding these modules in
some order.  This goal turned out to be unreasonable in that many
modules would have to be written in a subset of the full language,
thereby making them less maintainable.  Instead, we think the most
reasonable strategy for creating a new \commonlisp{} implementation is
to write it using the full language, and to bootstrap the new
implementation on an existing fully compliant implementation.

We think it is important that the code of
\sysname{} be of very high quality.  To that end, error messages
should be as explicit as possible.  Macros, for instance, do extensive
syntax analysis so as to prevent error messages from being phrased in
terms of expanded code.

To gain wide acceptance, \sysname{} is distributed according to a
two-clause BSD license.

We also plan to use this collection of modules, together with
additional specific code, in order to produce a complete
implementation of \commonlisp{}.

We think it is possible to improve on existing open-source Common Lisp
systems in several ways, and we hope \sysname{} will be able to
accomplish that, provided that great care is taken to create code with
a combination of characteristics:

\begin{itemize}
\item The code is layered, so that different Common Lisp
  implementations can choose to include \sysname{} modules that
  represent gaps in their system or improvement on their existing
  code, without having to include parts for which they prefer their
  own, implementation-specific code. 

  Upper layers contain code that is not performance critical.  This
  code is written entirely in Common Lisp.  If done well, code in this
  layer could be used by all free Common Lisp implementations, which
  could save considerable maintenance effort.  Examples of
  functionality in this layer would be formatted output,
  pretty-printing, and macros that can expand to portable Common Lisp
  code.

  Intermediate layers contain code that needs careful tuning to
  obtain performance, but where the tuning can be handled by writing
  different versions of the code for different cases.  For instance,
  functions that work on all kinds of sequences might have special
  versions for lists and vectors.

  Lower layers have to rely more and more on implementation-specific
  details, and require the introduction of implementation-specific
  primitives to be used in implementations of standard Common Lisp
  constructs.  We might provide several different versions of code in
  this layer for different low-level assumptions.

\item The goal is for the code itself to be of very high quality.
  By this, we do not only mean that it should be bug-free as much as
  possible, but also that it should have good documentation strings
  and clear comments when required.  We want error messages to be as
  explicit as possible, and to accomplish that we try to capture as
  many exceptional situations as is possible without performance
  penalties.  We use very specific conditions that are subclasses of
  ones stipulated by the Common Lisp \hs{} for condition
  signaling, so as to allow for implementations to take advantage of
  such specific conditions for better error reporting.  Macro
  expansion code should do everything possible to capture as many
  errors as possible so that error reporting can be done in terms of
  code written by the programmer, as opposed to in terms of expanded
  code.

\end{itemize}

